Collection of Internet/Collection of Internet.iso/infosrvr/dev/www_talk.930/001450_daemon _Fri Jun 25 22:14:17 1993.msg

Internet Message Format | 1994-01-24 | 6KB

Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
    id AA19369; Fri, 25 Jun 93 22:14:19 MET DST
Return-Path: <[e-mail]>
Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
    id AA19364; Fri, 25 Jun 93 22:14:17 MET DST
Received: from moose.cs.indiana.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
    id AA21664; Fri, 25 Jun 1993 22:37:30 +0200
Received: from localhost by moose.cs.indiana.edu
    (5.65c/9.4jsm) id AA07887; Fri, 25 Jun 1993 15:37:28 -0500
From: Marc VanHeyningen <[e-mail]>
To: [e-mail]
Subject: Encapsulating HTTP in MIME
Date: Fri, 25 Jun 1993 15:37:27 -0500
Message-Id: <[e-mail]>
Sender: [e-mail]

HTTP, particularly HTTP/1.0, is a transaction oriented protocol.  I
believe there are advantages to generating a mechanism whereby the
individual portions of the transactions (the REQUEST and the RESPONSE)
can be treated as MIME content-types, allowing separation,
encapsulation, forwarding, and the usual MIME stuff.

I (tentatively and roughly) suggest the creation of two additional
MIME types:

  message/http-request

and

  message/http-response

with their contents being identical to the request and response
messages of an HTTP transsaction, respectively.  Since the machine and
port of an HTTP transaction aren't represented within the request or
response explicitly, the request will need this as a parameter called
"host" or some such when it can't be assumed to be the machine reading
the request.

WHY DO THIS?

One advantage to this kind of method is that it should make it easier
for non-interactive users to utilize the full power of HTTP/1.0 via
mail messages sent to a mailbot that can take the http-request, send
it over the network as appropriate, and send back the result
encapsulated as an http-response.  This allows for precise tagging and
should help make a more automated environment for WWW users stuck on
UUCP or other dialup networks sending HTTP transactions via email (or
other means.)  The current mailbot, while servicable, is hardly
elegant; this could, in principle, let UUCP people (or people with
paranoid firewalls, or whatever) use XMosaic, just a bit slower.

The ability to encapsulate requests and responses inside other MIME
objects will also allow for Privacy Enhanced Mail (PEM) security
services, notably authentication, to be applied to HTTP transactions.
The problem of authorization to data may be handled by simply taking
the entire REQUEST segment, tagging it as an http-request, and signing
it with standard PEM techniques.  MIME-PEM interoperation is still an
internet draft, but the big issues are pretty much taken care of; only
minor syntactic matters remain.

The only real area of uncertainty I have is what HTTP request method
is appropriate for sending an encapsulated request to a server
directly.  It could use the PUT or POST methods, or a new method.
I'll use PUT for the moment.  Thus, a simple request to a mailbot
might look kind of like this:

  From: [e-mail]
  To: [e-mail]
  MIME-Version: 1.0
  Content-Type: message/http-request; host="info.cern.ch:80"

  GET /hypertext/WWW/TheProject.html HTRQ/1.0
  From: [e-mail]
  Accept: text/plain; text/html; image/gif; ...
  User-Agent: ...
  [ ... ]

and the mailbot would send back a message something like this:

  From: [e-mail]
  To: [e-mail]
  MIME-Version: 1.0
  Content-Type: message/http-response

  103 200 OK
  Last-Modified: <date>
  MIME-Version: 1.0
  Content-Type: text/html

  [the HTML document]

An authenticated transaction searching for information in an online
multimedia encyclopedia might look vaguely like this:

  PUT request HTRQ/1.0
  MIME-Version: 1.0
  Content-Type: multipart/pem; boundary="boundary"; privacy=mic-only
  Length: <whatever>

  --boundary
  Content-Type: message/pem-clear

  Content-Type: message/http-request

  GET /multimedia-encyclopedia/index?space+mission+moon HTRQ/1.0
  From: [e-mail]
  Accept: text/plain; text/html; image/gif; ...

  --boundary
  Content-Type: application/pem

  Proc-Type: 4,MIC-ONLY
  Originator-ID-Asymmetric: ...
  MIC-Info: RSA-MD5,RSA, [various signature information...]
  ...

  --boundary--

Thus, the *entire* HTTP request is encapsulated inside the
authenticated (and, if desired, encrypted) portion of the message;
this is important, since the whole request should be authenticated
(the first line is probably the most important thing to verify) and
protected by the PEM structure.

The preceeding example is based on the current internet draft
draft-ietf-pem-mime-02.txt; if you aren't familiar with it, the above
may look a little odd.  Naturally, "ordinary" requests and replies
would normally be used in situations not requiring services of PEM.

I believe this kind of content tagging has some general advantages for
increasing the ability to do HTTP transactions indirectly, and has the
distinct advantage of continuing HTTP's relationship with MIME and
closeness with "normal" mail.  Trying to force a PEM signature into an
HTTP Authorization: header or some such might be possible, but seems
like a bad idea to me.

I also believe that using PEM as a model for security services
continues the close relationship between HTTP and mail and is strongly
preferable to using Kerberos; I won't rant about this one right now
though.

Obviously, details and syntax and stuff would need to be fleshed out;
for example, it might be desirable to use unique identifiers
(Message-ID?) to allow clients receiving responses in batch mode by
UUCP to sort out which responses go with with requests.  In general, I
think this kind of development would be of use.

Reactions?
- Marc
--
Marc VanHeyningen   [e-mail]
MIME, RIPEM and HTML spoken here.